Gunnar Wolf: Now that we are talking about kernel building... What about firebuild?
After my last
post,
B lint (who prompted it with his last
post)
suggested I should do a hybrid test of his tests and my extremes. He
suggested I should build the Linux kernel using my Raspberry Pi 4 (8GB
model), but using the Firebuild build
accelerator.
Before going any further: I must make clear that while Firebuild is
freely redistributable, it is not made available under a free
license. It
is free for personal use or commercial trial, but otherwise requires
licensing.
B lint managed to build a Linux kernel in just over 8 seconds. So,
how did my test go? My previous experiment, using
Of course, having all of the object files built makes the rebuild
process quite faster (this is still done without firebuild). I
understand calling
Then, I did a first run using firebuild. Firebuild is a caching
build optimizer, so the first run will naturally be somewhat slower
(but if you often rebuild your kernel, it should be seen as an
investment). Now, in the Raspberry Pi, that uses a slow SD card
interface for its storage It is a heavy investment. The first time
I built with firebuild, it meant almost a 100% build time hit:
Not only that; I am using a fairly decent and big 32GB card, but this
is quite a big price to pay in such a limited system!
I did a build without cleaning the build directory, using firebuild,
and it does help although not by so much as in higher performance
systems:
So, it built in roughly 65% of the time it would take to build
regularly. And what about rebuilding without cleaning?
In this case, using firebuild worked roughly 30% slower than not
using it. I guess the high number of file ops inside
-j 4
, built Linux
in ~100 minutes; this was about a year ago, and I m now building linux
6.1, so I timed this again. To get a baseline, I built my kernel from
a just-unpacked tree, just as usual:
# cd /usr/src/linux-source-6.1
# make clean
# make defconfig
# time make -j4
(...)
real 117m30.588s
user 392m41.434s
sys 52m2.556s
make defconfig
without cleaning does not change
much, but I saw it often referenced in firebuild s docs, so I m
leaving it:
# time make -j 4
(...)
real 0m43.822s
user 1m36.577s
sys 0m40.805s
# cd /usr/src/linux-source-6.1
# make clean
# make defconfig
# time firebuild make -j 4
(...)
real 212m58.647s
user 391m49.080s
sys 81m10.758s
# du -sh .cache/firebuild/
4.2G .cache/firebuild/
# cd /usr/src/linux-source-6.1
# make clean
# make defconfig
# time firebuild make -j 4
(...)
real 68m6.621s
user 98m32.514s
sys 31m41.643s
# make defconfig
# time firebuild make -j 4
(...)
real 1m11.872s
user 2m5.807s
sys 1m46.178s
.cache/firebuild
are to blame, as in the case of the media I m
using, those are quite expensive; make
went its way basically
checking date stamps between *.c
and *.o
(yes, very roughly), and
while running under firebuild, I suppose each of these meant an extra
lookup inside the cache.
So Experiment requested, experiment performed!